Chapter 4

PP Tables

This chapter describes the purpose and syntax of the various tables used by PP. There are five basic tables used by PP, the aliases table, the users table, the domain table, the channel table and the or table. How these are combined and used to deliver and route messages is described below.

There are also a set of tables containing authorisation information and a family of tables that provide mappings between X.400 O/R names and RFC 822 domain names. Specific channels may also have their own tables containing the information they require.

4.1 Basic Operation of the Tables

When a message arrives, submit uses the domain, or, users, aliases and channel tables to identify delivery routes for the addresses in the message. The or2rfc, rfc2or and rfc1148gate tables are used to convert between X.400 style addresses and RFC-822 style addresses and vice versa.

The parsing of an address proceeds as follows:

• An address arrives in one particular form – either an X.400 style address or an RFC-822 style address.

• The address is normalised via the appropriate table – the or table for X.400 style addresses, the domain table for RFC-822 style addresses.

• There are three possible outcomes of the normalisation process.

1. The address is unrecognised

2. The address is recognised as a remote address.

3. The address is recognised as a local address.

• If the address is recognised as a remote address, routing information to the remote site is accessed via the channel table.

• If the address is recognised as local, the local address is first looked up in the aliases table.

If an entry is found in this table, the parsing process recurses with the value found in the aliases table.

If no entry is found in the aliases table, routing information for the local address is accessed via the users table.

• Having done the normalisation of the address and accessed the routing information for that address, the address is converted into the other style of address (i.e. X.400 style addresses are converted to RFC-822 style and vice versa) This conversion is done according to RFC-1148 and use the or2rfc, rfc2or, and rfc1148gate tables.

Note both styles of addresses are kept by PP. Also this conversion between styles is always possible.

• At this stage PP has parsed one style of address. If this parsing has resulting in routing information for that address, the address is valid. However the address still has to pass the authorisation stage before submit accepts it.

If the parsing does not result in routing information, the address is not valid in that form. PP then switches to the other style of address and attempts to parse that form.

There is a failure point. This occurs when PP decides all avenues and styles of addresses have been followed.

The tool ckadr can be used to check the action of parsing on various address.

4.2 The General Syntax of Table Entries.

In general, entries in the tables are in the form:

<key> ":" <value>

The only special character is : which if it appears on the LHS must be preceded by a backslash “\” to escape it. All other characters are copied verbatim. However, some tables undergo further processing and may need other escape sequences.

The purposes and details of the various tables now follow.

4.3 The Aliases Table

The aliases table governs the handling of aliases for user names. It is used for several reasons. These include:

• Mapping non-users to usernames. (e.g., “postmaster” to some “user”).

• Redirecting users who have moved (e.g., “fred” to “fred@foo.edu”).

• Rewriting users addresses (e.g., “jpo” to “j.onions”).

• Mapping aliases. (e.g., “list-request” to “j.onions”).

Entries in this table are constructed as follows:

<key> ":" <type>  <value> <qualifier>

The type describes the user name or address. This may be one of:

synonym: a new address, this name replaces the original value.

alias: a new address is given, but in some cases this name does not replace the original value. Aliases are not expanded for originators of messages whereas synonyms are. Aliases are also not expanded in the normalisation of addresses in message headers. Aliases, when expanded, add a redirect history element to the appropriate recipient of the message. Note this happens in the envelope but need not happen in the header.

The <value> is an address. It can be local or remote. The <qualifier> gives the interpretation of the value. By default this

is assumed to be a local user. However, full addresses can be specified with the appropriate qualifier. These are:

822: a remote RFC 822 user address is specified.

x400: a remote X400 user address is specified.

external: If this qualifier is present the name will not be lookup up again in the aliases file. This can be used for complex mappings. This qualifier is explained by example in Section 4.8

The format is best illustrated by a sample extract of the table as shown in Figure 4.1.

# sample aliases
#
mailgroup-request:alias Irene.Hassell
postmaster:alias Irene.Hassell
pp:alias postmaster
#
a.dacruz:synonym Alina.DaCruz
alina:synonym Alina.DaCruz
#
jpo:alias jpo@xtel.co.uk 822
#
pc:alias "/I=P/S=Cowen/O=xtel/PRMD=X-Tel Services/ADMD= /c=gb/" x400
#
f.bloggs:synonym f.bloggs@foo.bar 822 external

Figure 4.1: Example of Alias Table

The table includes an entry for a local alias mailgroup-request. The value Irene.Hassell is used as a key for a further search in the aliases table, but will not replace the alias in the message header; if no match is found, and since the entry is of type alias with no qualifiers, the address is assumed to be a local one and is used for accessing the user table. Also, if a local submission arrives from mailgroup-request then checking and authorisation will be done on the basis of mailgroup-request rather than

Irene.Hassell.

The next entries indicate that a.dacruz and alina are both synonyms for Alina.DaCruz. Here, the user’s address will be converted to Alina.DaCruz, and this value will be used in future table searches.

An entry is given for a remote RFC 822 user, jpo. The value of jpo@xtel.co.uk is parsed as an RFC 822 address.

Then follows an entry for a remote X400 user, pc. The value

     "/I=P/S=Cowen/O=XTel/PRMD=X-Tel Services/ADMD= /c=gb/"

would be parsed as X.400 address. The quotes (") are needed as the entry contains a space which is a field separator.

Finally, the entry f.bloggs is an external synonym. The address f.bloggs will be replaced by f.bloggs@admin.foo.bar for the originating address and further lookups of the aliases table will be disabled. It will not be replaced in recipient addresses to which delivery is being attempted. It may or may not be replaced for addresses in message headers depending on the tailoring. This is explained in greater detail in Section 4.8.

4.4 The Users Table

The users table determines the local delivery channel for a particular local user. It is formatted in the form:

     <username> ":" <channel> [ <mta> ]
                    ["," <channel> [ <mta> ] ...]

Channel: specifies the name of a local delivery channel on mta.

Mta: is the local machine on which the mailbox resides. If no MTA is indicated, the channel may be used for delivery by any MTA using these tables. If an MTA is present and is not the local machine (loc_dom_mta) then the message will be sent to that MTA by an appropriate channel and the channel parameter is effectively ignored - the normal routing tables will be used to reach that host. This should only be used for internal shuffling between several MTAs that are responsible for one domain.

A user can have several channels for local delivery. For example, in Figure 4.2 John.Taylor can have his mail delivered either by the 822-local channel or by the slocal channel. Which of these two channels is actually used for delivery depends on the format of the message being delivered.

##################### extract of `users' table ####################
#
Alina.DaCruz:822-local vs2.cs.ucl.ac.uk
Steve.Kille:822-local pyr1.cs.ucl.ac.uk
John.Taylor:822-local vs2.cs.ucl.ac.uk, slocal vs2.cs.ucl.ac.uk
Postie.Pat:822-local vs2.cs.ucl.ac.uk
x400-users:list
info-server:shell
#

Figure 4.2: Example of Users Table

This allows a user to have, for instance, X.400 format mail delivered by one channel, and RFC 822 mail by another channel.

Figure 4.2 illustrates how the various local users will receive mail and on which machines their mailboxes reside. An entry for a distribution list is also shown, and the entry for info-server shows the shell channel rather than a local delivery channel.

4.5 The Domain Table

The domain table is used by submit

• to derive a fully-qualified domain from any aliases or short-form names;

• and to obtain a pointer to the routing information for that domain.

See Section 7.7 on page 127 for a description of how to go about constructing this table.

Entries in the domain table are encoded in the form:

<LHS> ":" <qualified-entry> {"|" <qualified-entry>}
<qualified-entry> ::= <key> ["=" <value>] {[<key>["="<value>]]}

Left Hand Side (LHS) Constructions

LHS has two possible constructions:

dmn This construct is used for exact matches. No subdomains are allowed in this entry. This effectively sets min=0 and max=0 and cannot be altered.

*.dmn This construct is used to specify partial domain matches. Unless altered by the min and max keys described later, constructs of this form will match domains with at least one subdomain (i.e., min=1

and max=*).

Note that an entry of * with no domain components specified at all, represents the default domain. If the default domain is present in the domain table, then any top level domains which are not matched in the table, are matched by this default domain entry.

Qualified Entries

Each qualified entry may have several key=value components. The keys have two uses: to provide the information associated with the entry; and secondly to aid in matching the LHS. The possible types of key and what their values represent are as follows:

max=<number>: This specifies the maximum number of subdomains for the entry. A value of * indicates that the maximum number of subdomains should not be used when testing for a match. Effectively setting the maximum number of subdomains to infinity This is the default value for max on non-exact match entries.

min=<number>: This specifies the minimum number of subdomains for the entry. As with the max value above, a value of * indicates that the minimum restriction should not be used when testing for a match. Effectively min=0. The default value for min is 1.

norm=<dmn-name>: This identifies the fully-qualified domain name. If <dmn-name> isn’t specified, the fully-qualified domain name is taken as LHS (without the *. wildcard prefix if present).

mta=<chan-ref>: This provides a pointer to where the routing information for this domain is stored the channel table. If <chan-ref> isn’t specified, the pointer is taken as LHS (without the *. wildcard prefix).

norm+mta=<dmn-name>: This key is a combination of the mta and norm keys described above (i.e. norm+mta=<dmn-name> is the same as

norm=<dmn-name> mta=<dmn-name>).

mta+norm=<dmn-name>: This key is identical to the norm+mta key described above.

synonym=<dmn-name>: This identifies a synonym. The LHS key is replaced by <dmn-name> and parsing continues by looking for the new LHS in the domain table.

If the <dmn-name> is prefixed with the wildcard symbol *., the new LHS is constructed from <dmn-name> and the subdomains that a wildcard represents in the original LHS. For example a domain of foo.bar.zz matching an entry of *.zz:synonym=yy would result in a table lookup of foo.bar.yy. Note that this is only applicable to partial LHS entries.

local=<subtbl-name>: This indicates that LHS is local. Any host that needs to be recognised as local should have this keyword - this includes loc_dom_site. With no <subtbl-name>, this indicates that LHS is a local reference whose information is contained in the default tables aliases and users. With a <subtbl-name> specified, this indicates separate local alias and user tables. This feature is used when one MTA is supporting multiple local organisations, each with its own user and alias tables. This is described more fully in Section 4.8.

valid: This is shorthand for the entry norm=LHS e.g *.fr:valid is the same as *.fr:norm=fr. It implies that the domain is known but not routable directly. This may be used to indicate the domain is valid and may be used for RFC 1148 mappings. It may also be used to stop use of the default route. If a top level domain has an entry in the domain table, it will not be routed via the default route.

Domain table lookup

The right hand side of a domain table entry is a sequence of qualified entries. The qualification is based upon the number of subdomains below the key being looked up (i.e. the number of domain components the wildcard prefix *. represents).

For example, take the domain “1.2.3.xtel.co.uk”. When attempting to look this domain up in the table, several different keys may be used in the following order:

• “1.2.3.xtel.co.uk” the exact match,

• “*.1.2.3.xtel.co.uk” where the number of subdomains is zero,

• “*.2.3.xtel.co.uk” where the number of subdomains is one (i.e. * represents “1”)

• “*.3.xtel.co.uk” where the number of subdomains is two (* represents “1.2”)

• and so on.

PP will take the qualified entries in turn and choose the first one whose restrictions on the number of subdomain components is met by the number of subdomain components actually present. The restrictions for an entry are set by the min and max keys.

Note that all occurances of domain references in the domain table must be specified in US order (littleendian). If the appropriate flag is set, the routines accessing the domain table will “do the right thing” for UK ordering.

Domain lookup results

As mentioned above, the domain table is used to provide two items:

1. The fully-qualified domain name.

If a match is found in the table then this is always provided. If it is not explicitly provided by the norm key or a combination containing that key, then it is implicitly provided as the left hand side of the entry matched (i.e. the key used to index the domain table) For example with the entry

    xtel.co.uk:local

The fully-qualified name is xtel.co.uk. If the left hand side is a partial domain construct, the prefix *. is omitted from the fully-qualified name.

If any subdomains exist they are prepended to the fully-qualified name to reconstruct the full domain. For example with the entry

    *.gb:norm=uk

and the address xtel.co.gb, the fully-qualified name produced from the table would be uk. After the re-addition of the subdomains, this would become xtel.co.uk.

2. The pointer to the routing information.

The pointer into the channel table may be omitted. In which case the fully-qualified domain name has been derived but no routing information associated with it. This is useful when you wish to normalise the domain in message headers but you do not wish to deliver mail to that domain. It is also of use when the route to that domain is specifically an x400 route and as such the pointer to the routing information is specified in the or table described in Section 4.6.

Examples

Figure 4.3 contains several examples entries.

*.edu:mta=nameserver
cs.nott.ac.uk:mta=cs.nott.ac.uk
computer-science.nott.ac.uk:norm+mta=cs.nott.ac.uk
*.fr:valid
*.co.uk:min=0 max=0 mta=co.uk|mta=server.co.uk
*:mta=nameserver

Figure 4.3: Example of Domain Table

The entries in this figure imply the following actions:

• The *.edu entry will match all domain names with the most significant component of edu and at least one subdomain. Thus, the hosts

ucbarpa.berkeley.edu, prep.ai.mit.edu and foo.edu would all be

matched by this entry. However an address of user@edu would not be matched.

The fully-qualified domain name is constructed with the edu component as the most significant component.

The key nameserver will be used in the lookup of the channel table to find routing information for this domain.

• The cs.nott.ac.uk entry will only match the exact name cs.nott.ac.uk.

It will not match crg.cs.nott.ac.uk or admin.cs.nott.ac.uk.

The fully-qualified domain name is cs.nott.ac.uk.

The key cs.nott.ac.uk will be used to access the routing information in the channel table.

• The computer-science.nott.ac.uk entry will only match the exact name computer-science.nott.ac.uk. The fully-qualified domain name is cs.nott.ac.uk. This string is also used to access the routing information in the channel table.

• The *.fr entry will match all domains with the most significant component of fr and at least one subdomain. So it will match sorbonne.fr or nice.fr but it will not match fr by itself.

The fully-qualified domain name is constructed with the fr component as the most significant component.

No pointer to the routing information is specified. So when parsing addresses of the form nice.fr, PP will match this entry which indicates the correct domain ordering. However with no routing information for this form of the address, PP will convert the address to X.400 as described in RFC 1148 and then attempt to find routing information from the X.400 equivalent of the domain table – the or table.

There is a similar mechanism in the or table. Using these two mechanisms in tandem, you can keep pointers to X.400 routing information in the or table and pointers to RFC-822 routing information in the domain table.

As a side effect, because the top level domain fr has been matched, the default route will not be considered as a possibility.

• The *.co.uk entry has two qualified entries.

The first entry will only match the exact domain co.uk and nothing else.

The second entry will match all other domains with co.uk as the two most significant components i.e xtel.co.uk, bnr.co.uk etc.

The fully qualified domain name in both cases is constructed with the co.uk as the two most significant components. In the first case, there are no subdomain components to add so the domain name is co.uk.

The pointer to the routing information differs for the two cases. In the first case it is co.uk. In the second it is server.co.uk. This enables you to route differently depending on the number of subdomain components.

• The * entry is an example use of the default domain. It will match with anything that does not match any other rule. The fully qualified domain name will be the same as on input. The pointer to the routing information will be nameserver.

In the extreme case where you wish every domain to be routed via domain name server technology, this can be the only entry in the domain table.

Note: The default route should be used with care. It is tempting to use this as a catch all. This makes routing less efficient as every domain that uses this will be sent to one host, effectively passing the buck. It also means that users making small typo’s in the top level domain may have their mail routed a large distance before the mistake is found.

Note: It is usually sensible to put the relevant entries for the local domains in the domain table, especially loc_dom_site and loc_dommta—. If not local addresses will not be recognised as such.

4.6 The O/R Address Table

The or table provides routing and normalisation for X.400 address in the same way the domain table does for RFC 822 addresses. Lines are encoded in the form:

     <key> ":" <type> <value> ...

In the <key> field, the characters “:” and “.” must be preceded by a “\” character.

The <type> and <value> fields on the RHS are separated by white space, and so any space characters in those fields must similarly be preceded by either “\” or else the value should be encapsulated in double quotes.

The or table is used to evaluate O/R addresses. The <key> is encoded as dmn-orname as specified in RFC 1148 i.e. a sequence of <component>$<value> pairs separated by full stops.

The algorithm for O/R address analysis should be considered as a “treewalking” algorithm. The O/R address components are sorted, and components are looked up: first level 1; then level 2 + level 1 and so on. So repeated lookups are carried out, using this table. The first failed lookup breaks the loop with the last “routable” match (mta or local matches) being chosen as the result of the analysis. If there is no “routable” match, the analysis has failed and the O/R address is invalid.

There is a wildcard facility that may be used when constructing the LHS, <key>. To use the wildcard facility, set the <value> to the wildcard symbol *. For example, consider the case where you wish to route all unknown ADMDs under one country to one mta. This can be achieved by the following entry.

     ADMD$*.C$GB:mta admd.gb
Given the address /S=pac/O=XTel/PRMD=X-Tel Services/ADMD= /C=GB/,

the lookup of the O/R table will proceed as this • lookup C$GB, assume it succeeds

• lookup ADMD$ .C$GB, this fails

• lookup ADMD$*.C$GB, this matches the example entry

• continue looking up PRMD$X-Tel Services$ADMD$*.C$GB and so on

till lookup fails. When the lookup fails, the last successful mta or local entry is used for the appropriate routing.

There are four possible instances of the <type> field, similar in functionality and appearance to their counterparts in the domain table.

valid: This means that this part of the tree is OK. As lookup stops as soon as an entry is not found, it is necessary to mark entries which have no routing information as valid to allow lower entries to be found.

mta <mtaname>: This identifies the MTA <mtaname> as being associated with this vertex of the tree. This <mtaname> is a key into the PP channel table. The search should not stop at this point, as further tree searching may determine a more optimal mta.

synonym <dmn-orname>: This identifies a synonym, and indicates that all O/R components matched so far should be replaced with those identified on the RHS, and the search should now resume from the root. The characters “\” and “.” in the <component> and/or <value> parts of the dmn-orname construction must always be preceded by a “\”.

For historical reasons, this encoding has a second equivalent form:

alias <dmn-orname>.

local [<subdom-name>]: This identifies a local O/R Address. The remainder of the O/R address should be used to determine a local mailbox. If the subdom-name is empty the normal alias and user tables are consulted. If the subdom-name is present, then as with the similar feature in the domain table, this feature is used when one MTA is supporting multiple local organisations, each with their own user and alias tables. This is described in Section 4.8.

Figure 4.4 gives an example which shows the validity of some Country, ADMD, and PRMD values, and indicates which MTAs will deal with which PRMDs. The MTA value given here is internal to the PP lookup system, providing a key with which to reference the channel table.

4.7 The Channel Table

Submit uses the channel table to discover the possible channels, and in some cases relaying MTAs, that may be used to send a message on towards a remote host. This remote host is the one identified by the mta entries in either the or table or the domain table.

#
# extract of `or' table
#
#       -*** gb ***-
#
C$GB:valid
C$UK:synonym C$GB
ADMD$GOLD 400.C$GB:valid
PRMD$UK\.AC.ADMD$GOLD 400.C$GB:valid
OU$NoOrg.PRMD$UK\.AC.ADMD$GOLD 400.C$GB:mta NoOrg
#
#
#       -*** sites connecting via gold 400 ADMD ***-
#
PRMD$DIGITAL.ADMD$GOLD 400.C$GB:mta bt-gold
PRMD$TELECOM GOLD.ADMD$GOLD\ 400.C$GB:mta bt-gold
OU$CS.O$UCL.PRMD$UK\.AC.ADMD$GOLD\ 400.C$GB:local
#
#
#       -*** france ***-
#
C$FR:valid
ADMD$PTT.C$FR:mta emu-france
ADMD$ATLAS.C$FR:mta emu-france
PRMD$BULLMTS.ADMD$ATLAS.C$FR:mta MYBULL
PRMD$DERIEUX.ADMD$ATLAS.C$FR:mta persona
#

Figure 4.4: Example of Or Table

See Section 7.7 on page 129 for a method of building this table. The format of an entry has the form:

<key> ":" [ <mtaname> ] "("<channel>")"
      ["," [ <mtaname> ] "("<channel>")" ...]

key: is the index name derived from the mta entry in the domain or or tables – the remote host.

mtaname/channel: the mtaname derived from this lookup will be used as a key in the appropriate outbound channel’s table – the relaying MTA. If there is no mtaname present, then the remote host is reached directly through that channel. This sort of action is appropriate if the channel uses external information (such as the DNS) to look up the domain.

Figure 4.5 illustrates an extract of this table. There may be a number of possible channels for a given remote host.

Everything else being equal, the order of channels in the table is the preferred method of delivery. The authorisation process will select one of the possible channels and this is the one used.

#
#
a.cs.uiuc.edu:a.cs.uiuc.edu(smtp)
#
bsec.abcy.uwist.ac.uk:bsec.abcy.uwist.ac.uk(gb-janet)
bt-gold:bt-gold(x400out84)
bte:bte(x400out84)
abcl.co.uk:ukc.ac.uk(gb-janet),ukc.ac.uk(gb-pss)
btvax.ulster.ac.uk:btvax.ulster.ac.uk(gb-janet)
bull:bull(x400out84)
bunny.ulcc.ac.uk:bunny.ulcc.ac.uk(gb-janet)
#
emu-france:emu-france(x400out84)
#
torch.co.uk:ukc.ac.uk(gb-janet),stl.stc.co.uk(gb-pss)
#
# These are resolved directly by the DNS - no relay
edu:(smtp)
gov:(smtp)
com:(smtp)
us:(smtp)
mil:(smtp)
org:(smtp)

Figure 4.5: Example of Channel Table

4.8 Supporting Multiple Organizations on One MTA

PP contains several features that enable a site to behave as multiple mail hubs and/or as a central mail gateway between the external world and the internal subdomains. The features in question are:

• the local key in the domain and/or or tables,

• the external qualifier in the alias tables,

• and the -internal and -external flags to the header normalisation filters, p2norm and rfc822norm.

To explain how these features may be used, this section introduces three possible configurations. Each one slightly more complex than its predecessor. These examples consider the situation of two domains, the main site name, xtel.co.uk, and a subdomain under that site, admin.xtel.co.uk.

1. PP acting as two different, independent mail hubs.

This is the situation where one PP system is acting as two distinct domains.

The main domain xtel.co.uk has the information relating to its local users in the tables named users and aliases, and the subdomain admin.xtel.co.uk has the information relating to its local users in the tables admin-users and admin-aliases. There is no intersection between the xtel.co.uk name space and the admin.xtel.co.uk name space so these tables can be independently maintained.

PP has to be informed that admin.xtel.co.uk is a local domain. This is done via the relevant entry in the domain table and/or the or table. e.g.

     admin.xtel.co.uk:local=admin
     OU$admin.O$XTel.PRMD$X-Tel Services.ADMD$ .C$GB:local admin
2. PP acting as one name space divided over two adminstration
domains.

This is the situation where PP is acting as one complete name space composed of two separate adminstration domains, i.e. all users have mail addresses of the form user@xtel.co.uk.

As above the information about local users is divided into two separate sets of tables, users and aliases, and admin-users and admin-aliases. As above PP is informed that admin.xtel.co.uk is a local domain. But as these two domains are to be combined into one name space – xtel.co.uk, there has to be an intersection between the two sets of tables and in particular between the aliases tables.

The intersection only applies to addresses in the admin.xtel.co.uk adminstration domain. The delivery information for these users is stored in the admin-users table. On delivery, PP has to be able to access this table. Therefore it has to map from the address user@xtel.co.uk to user@admin.xtel.co.uk. This is done via an entry in the aliases table of the form:

     user:alias user@admin.xtel.co.uk 822

The entry is an alias because the mapping is only required when delivering a message to user. So for messages sent by user@xtel.co.uk,

the sender remains user@xtel.co.uk and not user@admin.xtel.co.uk.

The same is true for all occurances of user@xtel.co.uk in any headers they will be left as is. This also holds for x400 addresses and headers.

To ensure that the name space is maintained, one has also to ensure

that the address user@admin.xtel.co.uk is mapped to user@xtel.co.uk

for senders and in headers. This is so, because the user agents on the subdomain may stamp mail with their subdomain’s name i.e. admin.xtel.co.uk To acheive this mapping, there should be an entry in the admin-aliases table of the form:

     user:synonym user@xtel.co.uk 822 external

The external qualifier prevents this synonym being unwound if the responsibility for the address we are parsing is set (i.e we are trying to delivery to that address, it is for internal consumption). Unless the flags described below are used, the synonym is always unwound for addresses in headers.

WARNING: with the two entries in the two different aliases tables, there is a possiblility of circular aliases. The use of the external qualifier should stop most circles, but it is adviseable to use the ckadr tool to check some example addresses before going on-line with such a configuration.

3. PP acting as a gateway between the external world and the internal
domains.

The previous configuration suffices for a gateway between the outside world and the internal domains. However it may swamp the gateway machine with internal messages. All users are represented in headers as user@xtel.co.uk irrespective of which subdomain they are under. So any replies to messages will be directed to user@xtel.co.uk which is the gateway. It would be better if internal recipients of the message saw the internal addresses. Hence could bypass the gateway and send directly to the relevant domain.

This is an issue which doesn’t have any relevance for the parsing of envelope addresses. It only effects the headers presented to the user (both x400 headers and RFC 822 headers). As such, one has to set up the PP tailor file and routing information so that messages going to internal recipients have their headers reformatted differently than messages going to external recipients.

To obtain the different reformatting, one should tailor the -internal and/or the -external flags for the p2norm and rfc822norm filters. By default, the header normalisation filters unwind all synonym’s including those marked with the external qualifier. The presence of the -internal flag stops the filters unwinding the synonym’s marked

     external. Thus leaving user@admin.xtel.co.uk in headers.

4.9 RFC 1148 Mapping Tables

These mappings are used to convert between X.400 addressing and RFC 822 addressing. The mappings involved are not algorithmic, making necessary the use of such tables. RFC 1148 describes in detail their function. See Appendix D for how to obtains copies of the globally maintained tables in PP format.

4.9.1 The O/R to RFC 822 Table

The table or2rfc, exemplified in Figure 4.6, is for mapping OR names into RFC 822 addresses. The <key> is encoded as domain-syntax (see RFC 987 and RFC 1026) and value as dmn-orname. The longest possible match is sought.

     #
     #       -*** general GB ***-
     #
     PRMD$UK\.AC.ADMD$GOLD 400.C$GB:ac.uk
     ADMD$GOLD 400.C$GB:gold-400.gb
     #
     #       -*** via gold 400 ADMD ***-
     #
     PRMD$TELECOM GOLD.ADMD$GOLD 400.C$GB:telecom-gold.gold-400.gb
     PRMD$DIGITAL.ADMD$GOLD 400.C$GB:digital.gold-400.gb
     #
     #       -*** france ***-
     #
     ADMD$ptt.C$fr:ptt.fr
     PRMD$aristote.ADMD$ptt.C$fr:aristote.fr
     PRMD$BULLMTS.ADMD$ATLAS.C$FR:bullmts.fr
     #

Figure 4.6: Example of or2rfc Table

4.9.2 The RFC 822 to O/R table

Performing exactly the reverse operation is rfc2or, which has the <key> encoded as dmn-orname and the <value> as domain-syntax. An example of the format is given in Figure 4.7.

     #
     # extract of `rfc2or' table
     #
     gold-400.gb:ADMD$GOLD 400.C$GB
     #
     #       -*** via gold 400 ADMD ***-
     #
     telecom-gold.gold-400.gb:PRMD$TELECOM GOLD.ADMD$GOLD 400.C$GB
     digital.gold-400.gb:PRMD$DIGITAL.ADMD$GOLD 400.C$GB
     #
     #
     #       -*** france ***-
     #
     fr:PRMD$fnet.ADMD$ptt.C$fr
     ptt.fr:ADMD$PTT.C$Fr
     aristote.fr:PRMD$aristote.ADMD$PTT.C$Fr
     bullmts.fr:PRMD$BULLMTS.ADMD$ATLAS.C$FR
     derieux.fr:PRMD$DERIEUX.ADMD$ATLAS.C$FR
     #

Figure 4.7: Example of rfc2or Table

4.9.3 The Known RFC 1148 Gateway Table

The rfc1148gate table has the same syntax as the rfc2or table. Its entries represent gateways between X.400 and RFC 822 (via RFC 1148). This table is used in the cases where RFC 822 messages are relayed across an X.400 link. In such cases mapping to X.400 addresses may not always make sense as there will effectively be routing information encapsulated in the address. Normally this would cause the message to fail. However, if it is known that the destination is an RFC 1148 gateway, then the mapping can proceed in the expectation that the other end can unwrap the message.

An example RFC 1148 gateway file is shown in Figure 4.8.

ca:O$ubc.PRMD$cdn.ADMD$telecom\.canada.C$ca
uk:OU$CS.O$UCL.PRMD$UK\.AC.ADMD$ .C$GB

Figure 4.8: Example of RFC 1148 Gateway Table

4.10 PP Authorisation

Authorisation is applied after address parsing, normalisation and validation, to establish whether the message is permitted to be transferred on a per recipient basis. Address lookup may establish several possible outbound channels for each recipient; authorisation selects one of these after applying tests based on entries in the three authorisation tables auth.channel, auth.mta, and auth.user.

Access policy for channel pairs ( inbound + outbound ) determines how the rights for the four entities: sender, recipient, sending MTA, and destination MTA, are to be interpreted. ( “Rights” means one of the four values in/out/both/none and a fifth value “unset” to indicate that no table entry is present.)

The intention is that one of these four may be shown to be authorising the message (i.e., willing to pay for it).

It should be noted that authorisation is not applied to delivery report messages.

4.10.1 Access Policy

The access policy is one of the following:

none: Message may not be transferred.

free: No constraints on the four entities.

block ( i.e., “blockable” ): - at least one of the four entities must enable the message by specifying “in” or “both” for the inbound channel and “out” or “both” for the outbound channel. If none of the four enable it, the message may not be transferred. Therefore the default is to not let messages through. If a message fails in this mode, it effectively means that the message was not authorised.

negative: Any one of the four entities may stop transfer by disabling the message. This implies the default state is to let everything through, and special cases are stopped by explicit configuration. If a message fails in this mode, it effectively means that the message was prohibited.

When determining rights for a proposed transfer the following algorithm is followed:

• Determine the inbound and outbound channels and look up this pair in the auth.channel file.

If there is no entry in this file, take the default from the tailoring variable as the access policy for the channel.

• If the access policy is free or none, then the message is allowed through or rejected respectively.

• If the access policy is negative, check the MTA and user tables, auth.mta, and auth.user to see if this route is explicitly disabled.

• If the access policy is block, check the user and MTA tables to see if the route is explicitly enabled.

4.10.2 Table Formats

There are three tables associated with authorisation, plus the tailor variables.

Channel Authorisation

The first of these tables is the auth.channel table. This contains the overall policies for channel to channel relaying. As the key, the table has the syntax:

<inchannel> "->" <outchannel>

If no value is found for the above, then as a fallback the values

<inchannel> "->" "*"
"*" "->" <outchannel>
"*" "->" "*"

are checked in that order.

The values that the table can have are as follows:

<policy>: Any of the above mentioned policies (free, block etc.).

warnsender=<file>: Send a warning message to the sender if the authorisation fails, with text taken from the given file (relative to the wrndfldir).

warnrecipient=<file>: Send a warning message to the recipient with text taken from the given file if the authorisation fails..

sizelimit=<digits>: Enforce the given size limit on messages. No messages larger than this size will be relayed. This is obeyed regardless of the overall policy of the channel. (I.e., A channel may be marked as free with a sizelimit, and the sizelimit will still be enforced.)

test: This setting modifies the checking procedure to always allow the message through. However, all the checking is carried out and the result is logged. This is useful to test out the results of a setting for a while before fully applying them. If either warnsender or warnrecipient is set, the warning message will be sent if the message would have normally failed the authorisation checks.

If warning messages are to be sent, the contents of the message are subject to macro expansion. The macros of the form $(key) are replaced with given values, as shown in Table 4.1.

An example of the auth.channel table format might look like the following:

822-local->pss:free
822-local->local:block
822-local->slocal:free
822-local->smtp:free, warnsender=smtpwarnsender, test
822-local->janet:block, sizelimit=4000
x400in84->x400out84:none
x400in84->local:free,sizelimit=10000
822-local->x400out84:block,warnsender=restricted, test
smtp->smtp:block, test

Key  Expansion

sender the address of the sender of the

message (original format)

822sender the address of the sender (rfc822

format)

400sender the address of the sender (x400

format)

recip the address of the recipient of the

message (original format)

822recip the address of the recipient (rfc822 format) 400recip the address of the recipient (x400

format)

ua-id the user agent id of the message p1-id the P1 id of the message locsite the local site name locmta the local mta name reason The reason for authorisation fail-

ure

direction if the message is destined for the sender or the recipient

Table 4.1: Warning Message Macro Expansions

MTA authorisation

The next table is the MTA policy table in file auth.mta. This governs the policy for a given MTA if the channel policy is not free or none. The keys used in this table are the source MTA and the destination MTA. Each of these are looked up separately to determine policies.

The allowed values for this field are any of the following in a commaseparated list:

<channel>=<direction>: This specifies for given channels what directions are allowed for this MTA. The possible directions are:

in: Allow inbound traffic for this channel.

out: Allow outbound traffic for this channel.

both: Allow both inbound and outbound traffic for this channel.

none: Allow no access for this channel.

default=<direction>: This specifies the default directions that traffic can flow in the absence of a particular channel being specified.

requires=<pattern>: This MTA requires that the sender/recipient address being authorised matches the given pattern. This is a standard regular expression as specified in regex (3). excludes=<pattern>: The MTA requires that the user being autho-

rised does not match the given pattern.

    bodypart-excludes=<bodyparts>: This specifies a list of bodyparts

that the MTA will not accept. These bodyparts are taken from the list of standard bodyparts as described in Section 3.2.1 on page 18.

sizelimit=<digits>: The MTA will not relay messages larger than the given sizelimit.

An example of this table might look like the following:

     vs2.cs.ucl.ac.uk:default=both, smtp=out, x400out84=out,
             822-local=in, excludes="A.DaCruz.*"
     localhost:default=in, x400in84=out, smtp=both,
             822-local=none, sizelimit=654321

(Lines are folded for readability.)

User Authorisation

The user table is where both the recipient and originator are looked up to determine access rights. The key is either the full normalized name of the user, or if local, just the local part of the name. The values may contain any of the following:

<channel>=<direction>: This specifies, much as for the MTA, what directions are allowed for this user.

default=<direction>: This gives the default directions allowed for this user.

    bodypart-excludes=<bodyparts>: A list of bodyparts that are not

allowed to be sent to the user.

sizelimit=<digits>: Disallow messages larger than this sizelimit.

An example of the user authorisation table is:

     j.taylor@cs.ucl.ac.uk:default=both
     /I=J/S=Taylor/OU=cs/O=ucl/PRMD=uk.ac/ADMD=gold 400/C=gb/:\
       bodypart-excludes=g3fax|dmd, sizelimit=100000, 822-local=both
     a.dacruz@cs.ucl.ac.uk:default=both
     s.kille@cs.ucl.ac.uk:default=both
     p.cowen@computer-science.nottingham.ac.uk:default=both, \
            822-local=in, x400out84=none
     j.onions@computer-science.nottingham.ac.uk:default=both

4.11 Authentication

Components of PP must do appropriate checking that they are being invoked correctly. Note that authentication is complementary to authorisation. It is also a prerequisite.

4.11.1 Submit Authentication

Submit needs to verify the source of an inbound message. For messages from an inbound channel (protocol server) accessing the MTA Abstract Service, this means verification of the UID of the channel (typically to be “root” or “pp”). For the MTS Abstract Service, the identity of the P1 originator must be verified. These two verifications use the same mechanism. There are two cases:

1. Submission from a local process using pipes. In this case, the UID of the invoking process is available, and can be the basis for authentication.

2. For remote submission, the UID is not available, and so a password based mechanism is used. This may also be used locally.

A password and the corresponding name are carried in the initial protocol handshake. This may be overridden for later messages.

Each (inbound) channel has an “auth-table” variable, which identifies a table which is used in the manner described below. The authentication table has three columns. These have the following meaning:

1. String-encoded address, in the preferred format of the channel:

• X.400 O/R Address.

• RFC 822 address.

2. List of valid UIDs.

3. Password (as in /etc/passwd).

Example files:

     #
     # Start of dummy 822 file
     #
     S.Kille@cs.ucl.ac.uk:steve|aiohpefcn
     #
     # Dummy X.400 file
     #
     /i=s/s=kille/ou=cs/o=ucl/prmd=uk.ac/admd= /c=gb/:steve,pp
     /i=j/s=onions/o=nott/prmd=uk.ac/admd=gold 400/c=gb/:jonions

4.11.2 QMGR Authentication

Management tools like the MTAconsole can connect to the qmgr in two distinct modes. These are

no authentication: In this mode, no authentication is done for the user. weak authentication: In this mode a name and password are passed

across in the bind, so there is some limited authentication of the initiator.

When an incoming call is received by the qmgr, authentication information is checked in the auth.qmgr table. The format of this table is:

<name> ":" "passwd=" <password> "," "rights=" <rights>

These parameters are interpreted in the following way:

name: This is the name given in the bind parameters. If the connection was bound with no authentication, the name anon is used for the lookup. If the name is not found in the table, then if the user bound with authentication, the request is refused. If the user bound without authentication, and the name anon is not present in the table, then limited access is allowed.

passwd: This value takes an encrypted passwd, which can be generated with the utility mkpasswd. The password passed in the bind information is encrypted and compared against this value if present. If no passwd field is present, then a passwd is not required.

rights: This value is used to indicate the rights that the initiator will be allowed. It may be one of the following values:

Value  Meaning

none The association is refused.

limited The initiator is allowed to examine the queue but not to change any parameters. full The initiator is allowed to examine the queue

and modify queue paramters

If it is missing, then limited access is assumed.

For example:

anon:rights=none
admin:passwd=YNKJHgaawczz,rights=limited
pp:passwd=YNKcyeOsT6Fqc,rights=full

In this case the following is true:

anon: Unauthenticated users are not allowed any access to the QMGR.

admin: The user admin with the correct password is allowed to view the queue.

pp: The user pp, with the correct password, is allowed full access to control the queue manager.

If no table is specified, limited access is allowed for any connection.

4.12 The 822 Local Table

The ch.local table is an example of a table accessed by different channels; both 822-local and slocal channels use it in order to find out where and how to delivery mail to registered users. The LHS is the registered users mail address. The format is of the RHS is of the form “key=value.” The following table of key/value pairs are allowed:

uid The numeric user id to deliver the message as.

gid The numeric group id to deliver the message as.

username A username found in the password file. If this entry is set, it sets defaults for uid,gid,shell,home and directory.

directory The directory to change to before starting delivery. This implies CWD for any files which use relative path names. If it is not set it defaults to home.

mailbox The name of the mailbox if default delivery is being done.

shell The user’s shell and the one which is exec’d to run pipes etc.

home The user’s home directory.

mailformat The default format to deliver mail in; this can be either pp for MMDF/PP style mailboxes or unix for sendmail compatible style (the default is pp).

restricted this is set to true if the user is restricted. In restricted mode the user cannot run arbitrary programs on delivery and cannot change the PATH environment variable.

mailfilter The mailfilter file to use. This defaults to the name of the mailfilter global tailor variable in the users home directory. A value of none disables this feature.

sysmailfilter The system default mailfilter file. This defaults to the global tailor entry. A keyword of none disables this facility.

searchpath The directory to look for binaries that the user can run in restricted mode.

opts other options; not currently used.

If the resticted mode is in force, then the .mailfilter file processing is reduced in functionality as follows:

• The user is not allowed to set the variable PATH to search other directories for programs. (Actually this variable can be set, it is just ignored.)

• The processes executed by the pipe command must be in the directory named in searchpath (defaults to USRBINDIR defined in the Make.defs file).

• The processes executed by the pipe command must be executable by the system call exec(2). (E.g. redirection and shell syntax will not be obeyed).

For an entry in this table to be valid, it must either contain at least a UNIX login id, or have a userid/groupid/directory to deliver to.

For example:

     Alina.DaCruz:username=alina home=/cs/users/vs1/alina
     John.Taylor:username=jtaylor
     Postie.Pat:username=pp
     bug-filter:uid=32767 gid=1001 mailbox=/usr/spool/mail/bugs mailformat=unix

Note: for compatability with earlier releases the following format is allowed:

     name ":" <unix ID> [<home directory> [<file>]]

4.13 The X.400 (1984/1988) Outbound Table

This table is used by the outbound X.400 channels, allowing them to map the host name to the information needed for addressing of and connecting to the remote MTA. The key in this table is the value representing the MTA derived from the “mtaname” field of the channel table. The value is a set of key=value fields separated by white space and/or commas.

     mta key:rmta=xx,rpass=xx,rpsap='"591"/Janet=000005110000'

The mta key is the key from the address lookup. This is the remote host to which the outgoing connection it to be made. The following keys are recognised in the value field. The format of these keys are common to both the outbound and inbound X.400 tables and as such are described here and not under the X.400 inbound table section.

lmta: The name of the local mtaname to pass in the RTS connect parameters.

lpass: The passwd of the local site to pass in the RTS connect parameters.

rmta: The name of the remote MTA to pass in the RTS connect parameters. If this is not set, then no authentication will be specified in the RTS connect.

rpass: The name of the remote password to pass in the RTS connect parameters. There is no default for this and it should not be set if the rmta is set.

rpsap: The remote presentation address. This is specified in the string encoded format. Note that session selectors and presentation selectors should always be absent in the 1984 RTS. This is the only mandatory key on the RHS of the X.400 outbound table. lpsap: The local presentation address. This is only necessary if you

need to claim to originate from a specific selector or network address. Normally this parameter is not specified.

mode: The mode of RTS connection. This is either mon for monologue (the default) or twa for two way alternate. This only governs the mode passed initially, it does not imply that the channel will work in TWA mode.

type: The type of RTS connection. This is one of the following:

Value  Meaning

1984 Use the 1984 protocol mode (default).

1988-X410 Use the 1988 X.410 mode protocol,

1988-normal Use the 1988 normal mode protocol.

1988 Use the 1988 normal mode protocol (same as previous).

Obviously, this information is dependent on the capabilities of the channel (a 1984-based channel will not be able to use the 1988 protocol).

trynext: A key to another entry in the table. If a connection using the current information fails, the outbound channel will look up this key and try making a connection using that data.

tracing: The style of tracing information to use. It may take one of the following values:

Value  Meaning

admd Remove all but the first tracing com-

ponent.

nointernal Remove all internal tracing compo-

nents.

local-internal Keep only internal trace related to the current PRMD.

all keep all tracing information

The default value is all.

The admd mode should only be used when talking to a particularly restrictive ADMD. Again, it depends on the capabilities of the channel how closely this information can be followed.

rname: The “real” name of the remote MTA. This is an entry that is suitable for lookup in the domain table. It is not used for the outbound channel.

fix-orig: This applies an on-the-fly change to the originator address. The syntax is

              "fix-orig=" <old-or> "->" <new-or>

and might be applied as

              fix-orig="/ADMD= /C=GB/->/ADMD=Gold 400/C=GB/

to change the ADMD from space, to Gold 400 in the originator for outgoing messages to specific hosts.

This key is only used by the outbound table.

other: Other information. This is a string and is interpreted by the channel to allow other types of operation to be specified. It is not currently used by the X.400 outbound channels.

It is used by the X.400 inbound channels. If other is set to sloppy, the inbound channel will not check against any rpass specified in the inbound table.

If an entry with a key default exists in the table, then this may be used to set default setting for all entries. The value default is looked up first and values filled in from that setting, then the real entry is looked up and those values override the default entry.

An example outbound table is shown in Figure 4.9 (lines are folded for clarity).

default:lmta="us",lpass=" ",
germany-nixdorf:rmta="nme",rpsap='Int-X25(80)=26245300042203'
france-derieux:rmta="persona",rpsap='Int-X25(80)=208075200131'
france-reunir:rmta="sunir.reunir.fr",
              rpsap='Int-X25(80)=20803500034996'
pp-nottingham:rmta="pp.cs.nott.ac.uk",
              rpsap='"591"/Janet=000021000018+PID+03010100'
vs2.cs.ucl.ac.uk:rmta="vs2.cs.ucl.ac.uk",
              rpsap='"591"/Internet=vs2.cs.ucl.ac.uk'

Figure 4.9: Example of X.400 Outbound Channel Table

4.14 The X.400 (1984/1988) Inbound Table

This table is used by the inbound X.400 channels, and allows the channels to obtain the MTA name and other information from the OSI calling address. The syntax is the same as the X.400 outbound table, only the key is different.

The key here is the information given in the session connection of the remote calling host; the values are as indicated for the outbound table. It is encoded in the string encoding for presentation addresses using no macro substitution. Therefore, the keys look pretty horrible. It is usual to maintain these tables with keys in macro form and run them through the utility nsapexpand to expand the macros.

The matching of incoming information with an entry in this table provides the major security checking. Again an entry default in the table may be used to default many of the fields.

An example inbound table is shown in Figure 4.10 (again lines are folded for clarity).

default:lmta="us",lpass="bar"
"3459"/Int-X25(80)=208006030203:rname="france-kwai",
       rmta="kwai.inria.fr"
"425"/Int-X25(80)=26245622190113:rname="germany-ibm",
       rmta="foo",rpass="foo"
Janet=000021000018:rname="pp-nottingham",rmta="cs.nott.ac.uk"
Janet=000005111680:rname="pp-vs2",rmta="cs.ucl.ac.uk"

Figure 4.10: Example of X.400 inbound Channel table

4.15 The List Table

The ch.list table is used by the list channel to expand local distribution lists. Entries in this table have the format:

<listname> ":" [<moderator> "|" ...] ","
   file=<filename> | <mail address> "|" ... ","
   description

listname: The name of the distribution list, e.g., listname. Note that in order for the list to form a valid local address, the local part of the name, listname in the above examples, must have an entry in the local users table, specifying that messages addressed to the list should be delivered via the list channel.

moderator: The UNIX ids/login names of the moderators of the list. This element of the table entry is purely for the use of the distribution list management tool, mlist (see Volume III (The PP Manual: User’s Guide)). Anyone with one of the specified uids may use mlist to modify the contents of the list.

file: The file containing the members of the list. If <filename> is not a fully qualified pathname, the required file will be assumed to be under the tbldir directory structure. The format of such files is one member’s address per line. Note that the file must exist for mlist to be able to be used on the corresponding list (i.e. mlist is unable to create the files only modify them). Any lines in this file starting with the character # are ignored.

mail address: An address of a member of the list. Note that because they are specified in the list table itself, mlist cannot be used to modify such members. description: A short description of the purpose of the list. This de-

scription is output by mlist when requested.

Note that in order to form a valid entry in the list table, each entry must be on one line and must contain two and only two commas.

Comment line in tables start with a #. The list table extends this mechanism further. Comment lines that are printed by mlist start with #Comment:. This allows the list table to have two levels of comments, one for the editor of the list table and one for the user of mlist.

#
# extract of `list' table
#
#Comment: -*- Example lists -*-
filelist:pac,file=/crg/pp/mainlist,a list with members in a file
strlist:pp|pac,p.cowen|j.onions|g.lunt,a list with members in line
mixedlist:jpo,j.onions|file=mixedlist,another list
#

Figure 4.11: Example of List Table

If you have a large sendmail alias file to convert, you may find the utility make-lists(8) of use. make-lists(8) is found in the Tools directory. This utility attempts to convert lists of names into a format suitable for use in the list channel of PP. Note: it does not convert all alias table entries, only lists.

4.16 The Shell Table

The ch.shell table is referenced by the shell channel when converting from the recipient address to the commands to execute in its place. Entries in this table have the format:

     <address> ":" <user id> "," [<timeout period>['|'<qualifier>]]
                  "," <command line to execute>

address: specifies the recipient address, e.g., shellprog. Note that in order for this to form a valid local address, the local part, shellprog in the examples, must have an entry in the local users table, specifying that messages sent to the address should be delivered via the shell channel.

user id: specifies the user to run as when executing the commands. This id is resolved using /etc/passwd. Alternatively it may be specified as <uid>/<gid> to run as an arbitrary user and group.

timeout period: specifies how long, in seconds, the commands should be allowed to run before the shell channel kills them off. If the timeout period is not specified, the commands are allowed to run for the default period of time, five minutes. If the period is zero

Key  Expansion

sender the address of the sender of the

message (original format)

822sender the address of the sender (rfc822

format)

400sender the address of the sender (x400

format)

recip the address of the recipient of the

message (original format)

822recip the address of the recipient (rfc822 format) 400recip the address of the recipient (x400

format)

qid the queue id of the message (e.g., msg.a000000) ua-id the user agent id of the message p1-id the P1 id of the message userid The username or ID of the deliv-

ery process

groupid The group name or ID of the delivery process size The size in bytes of the message channelname The name of the delivery channel

Table 4.2: Shell Channel Expansion Macros

then the shell channel will not enforce a time limit for the commands.

qualifier: qualifies the behaviour of the shell channel. This qualifier is optional appended to the timeout period with a | seperating the two values. If the qualifier is set to the string solo then the shell channel will restart(fork) the command line for each bodypart.

command line: specifies the command line to execute. If the program name is not a fully qualified pathname, the program is assumed to be under the directory specified by chandir. Arguments of the form $(key) will be expanded as described in Table 4.2.

When running, the shell channel pipes all the message body parts, in order, to the program’s standard input. The shell channel understands an exit code of 0 as success and otherwise as failure.

An example of a shell table is shown in Figure 4.12.

4.16.1 Statistical Logging

Each line in the statistics log (“stat”) either logs the status of inbound messages, or delivery reports that are generated, or notes a message that is

##################### extract of `shell' table ####################
#
nullshell:pac,60,sh -c "/bin/cat > /dev/null"
usefulshell:jpo,,usefulshellprog $(ua_id)
lynx:pp,0|solo,/usr/ucb/lpr -Plynx
#

Figure 4.12: Example of Shell Table

delivered. Amongst the parameters logged are:

• A success indicator ( e.g., “ok” or “DR” ).

• Unique message id.

• A P1 message ID.

• Inbound channel→outbound channel.

• Sender.

• Sending MTA.

• Recipient.

• Destination MTA.

• Message size.

• A diagnostic message. Fields are space-delimited and double quoted where necessary. Duplicate recipients are eliminated (second and subsequent) if there is an

exact match on the 822 or X.400 address (as appropriate), not the original entry.

Channel binding is performed after all other tests have been passed, and takes into account any body parts actually received but not specified in the message header.

Unsuccessful recipients are flagged to generate nondelivery reports. The tool statp, found under the Tools directory, takes the statistics log

and converts it to something suitable for processing via awk or other such processing tools. There are several example awk scripts under the source directory Tools/statgen.